In the field of the distributed computing, several architectures exist to allow machines to communicate with one another or to share distributed or net-centric applications. One of these architectures includes the Common Object Request Broken Architecture (CORBA). CORBA is an architecture design specification developed by the Object Management Group (OMG), an independent group devoted to developing standards for use in object-oriented computing. Examples of CORBA-compliant systems include Netscape's ONE product, and BEA System's Weblogic Enterprise Server.
CORBA provides a specification for the Interface Definition Language (IDL), which allows software developers to define interfaces to their object-oriented applications in a standard fashion. IDL includes mappings that allow IDL definition and types to be mapped to a variety of programming languages, including C, C++, and Java. Thus, CORBA allows developers to create “transparent” applications, which may be interpreted independent of the original programming language. Developer and third-party vendors create objects which interact with one another through an Object Request Broker (ORB). Using language mappings, developers can create client-side “stubs” and server-side “skeletons”, which the ORB's understand.
Since CORBA 2.0, the CORBA specification has included a method to allow ORB's to communicate seamlessly with each other. The ORB Interoperability Architecture, or more specifically, the General Inter-ORB Protocol (GIOP) standard, defines a set of message requests which ORB's may make over a network. Various flavors of GIOP exist, each tailored to the needs of a specific network transport. GIOP as defined by the OMG, comprises three components:
The Common Data Representation—a transfer syntax mapping IDL types to low-level types for use between network agents.
The GIOP Message Formats—of which there are currently seven, including client request, server reply, client cancel request, client locate request, server locate reply, server close connection, and message error.
The GIOP Message Transport Assumptions—including that: the transport is connection-oriented, reliable, can be viewed as a byte stream, provides reasonable notification of disorderly connection loss, and that the transport's model for initiating connections can be mapped onto the general connection model of TCP/IP.
A common GIOP implementation, which all ORB's must by specification be able to use, is the Internet Inter-ORB Protocol (IIOP). IIOP maps GIOP messages to TCP/IP, allowing the ORB to use a TCP/IP network, for example the Internet, as a communications bus or backbone. Referring to the pyramid structure 20 of FIG. 1, at the lowest level of the pyramid exists the Physical Device 22, for example an Ethernet card having a MAC (Media Access Control) address. Upon this sits the Ethernet protocol 24, which provides a connection-based, broadcast topology where messages are encoded and collisions resolved. The next layer is the Internet Protocol (IP) 26, which specifies the format of packets that traverse the Internet and supports hostnames and IP addresses. The hostname allows IP to be routed. Above IP is the Transport Control Protocol (TCP) 28, which adds the functionality of port number and control directives such as packet segmentation and time to live. This provides reliable, stream-based delivery. IIOP 30 is built upon TCP. Above IIOP sits the ORB level 32, which marshals the IIOP requests. At the top of the pyramid is the application level itself 34, which includes object implementations and other ORB objects and services, such as the Naming Service.
In such a distributed Object System as described above and, as further illustrated in FIG. 2, requests 50 are passed back and forth between processes requiring an object's function 42, 44, 46, 48 and the processes implementing an object's function 52, 54, 56, 58. The example of FIG. 2 shows n clients invoking upon m servers. With such a system 40 it is difficult to achieve scalability when there are n×m connections, where n represents processes requiring a group of object function and m represents the processes implementing the group of object functions. This is commonly known as a “fan-out problem”, and leads to difficulties in ensuring system resources are sufficient enough to allow scalability. Techniques exist to allow concentration of requests through a concentrator process to an IIOP/ORB domain or group of object implementations. The problem is how scalability may be achieved going in the opposite direction, from the object implementations within the domain, to other object implementations outside of the domain.